A large integration between IP and PLMN networks is under way to the benefit of wireless customers who may enjoy a lot of attractions offered by IP over traditional telecommunications protocols and in meanwhile experiencing “seamless” communications over the different types of networks which their calls may pass. This facilitates a wide diversity of communications scenarios and combination of services such as the exchange of real-time multimedia streams during voice calls. The core of the IP-PLMN integration is a 3GPP platform named IMS which has been introduced appositely to offer to the operators, the service providers, and the clients the sort of service capabilities that IP is designed to provide. The primary focus of the IMS platform is that to provide the users/clients with the ability to join multimedia session in which they are allowed to send and receive voice and data communications even when roaming. The IMS will use the emerging IP version 6 (IPv6) together with SIP protocol for the establishment of sessions and the service provisioning on mobile networks. SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with two or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, presence service and multimedia distribution, etc. SIP supports user mobility by proxying and redirecting requests to the user's current location. For more details see [RFC3261] at the end. For the same purpose [TS—22.228] identifies the necessary requirements from the user point of view. The reference architecture for IMS subsystem can be found in [TS—23.002]. A more exhaustive description of the involved entities can be found in [TS—23.228].
SIP is based on an HTTP-like request/response transaction model; each SIP transaction consists of a request that invokes a particular method, or function, on the server and at least one response. A header is a component of a SIP message that conveys information about the message, it is structured as a sequence of header fields. Header fields are named attributes that provide additional information about a message. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) [RFC2327]. The SDP body is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message: for HTTP see [RFC2616]. A SIP request message named “MESSAGE” is introduced by the specification [RFC3428]) to carry in the request body the information needed to set up a specific service. MESSAGE is a very flexible SIP request message supported by every SIP platforms and SIP Application environments. In fact, it is a generic asynchronous SIP message that can be used inside or outside to the session. It is also possible to specialize its structure according with the service requirements. A header field “Subject” of the SIP MESSAGE Request provides a summary or indicates the nature of the SIP MESSAGE message, allowing call filtering without having to parse the session description. In the scope of supplementary service the [TS—24.081] document is a relevant prior art which specifies the procedures used at the radio interface for the following items: normal operation, registration, erasure, activation, deactivation, invocation and interrogation of line identification supplementary services. Particular relevance assume the Calling Line Identity (CLI) clauses 1 (CLIP) and 2 (CLIR). The CLI consists of a calling party BCD number and optionally, a calling party subaddress and/or a cause of no CLI. The purpose of the calling party BCD number information element is to identify the origin of a call; it is a type-4 information element. In the network to mobile station direction it has a minimum length of 3 octets and a maximum length of 14 octets. This information element is not used in the mobile station to network direction. The calling party subaddress is a type 4 information element with a minimum length of 2 octets and a maximum length of 23 octets, its purpose is to identify a subaddress (IMEI) associated with the origin of a call. When calling line identification restriction is applicable, the originating network provides the destination network with a notification that the calling party's ISDN number, with possible additional address information, is not allowed to be presented to the called party.
The Call Line Identity (CLI) is a service actually implemented to enable the end user to see who is calling his mobile device, is a feature which most mobile (and fixed) users take for granted. The existing CLI is a poor type of service indeed, all information that is possible to get is carried by only few bytes limitedly to the only downlink. This is in strident contrast with the great opportunities of service offered by the IMS platform and the expectations of the users.